Computer networks are having more and more of an impact on human interaction with the passage of time. For one example, the Internet, which is currently used by only about 5% of worldwide human population, is being recognized as a boon to mankind. Accordingly, the Internet, is rapidly growing in usage on a global basis, is bringing a vast array of useful information to those members of our global village who are Internet users, and is fostering communication between diverse cultures located around the globe by way of the email system. As is widely known, the Internet has its foundation in globally-deployed computer networks. For other examples, one could cite rapidly growing non-Internet local area network (LAN) usages of computer networks in industry, academia, government, and elsewhere. Accordingly, information (traffic) on all of these networks is building at an accelerating pace which is creating an urgent need for finding additional solutions to network traffic congestion and traffic-induced network-instability problems.
One such solution involves the use of what is known in the art as “tunnels”. These are computer software/protocol network-constructs which typically employ “labels” as in the multi protocol label system (MPLS). For example, these labels can override destination addresses in the headers of network information or data packets received at a router. This router may be the input router to a particular tunnel, where the labels allow forwarding such network information or messages or binary-styled data packets from the input router via the tunnel to its exit located on its tail-end router or network device. These tunnels can provide rapid movement of traffic from entrance to exit devices, thus reducing the handling of this traffic at every network device or node therebetween and speeding-up the process of communication. In other words, traffic engineering tunnels are used to direct traffic along a predefined path, which may differ from the path that IP routing (Internet Protocol routing) would have otherwise determined. This one network feature, tunneling, can thus be a step in the right direction with regard to solving or managing the increasing network traffic problem.
However, tunnels have certain limitations. One of the problems with tunneling is that it can cause network instability as it is being incorporated is into a network. For example, consider a tunnel being created between an ingress or head-end router and an egress or tail-end router in a network having a number of other routers, switches, and other network nodes with links connecting all devices. Traffic that is upstream of the tunnel's ingress router and destined for routers downstream of the tunnel's egress router will be directed towards the ingress router to try to get a “quick ride through the tunnel”. This creates an instability in the network since traffic across the network, which otherwise would or should have been generally uniformly distributed, is being subjected to a perturbation caused by a single tunnel being introduced into the network and attracting traffic to its head-end. In other words, normally when an MPLS Traffic Engineering (TE) tunnel is created, it causes an aggregation of traffic to the tunnel's tail-end router, since the newly created tunnel appears to be the best path to all destinations beyond the tail-end router. In many cases this is not desirable. When initially configuring MPLS TE tunnels, there is a problem with network stability; but, once tunnels are configured everywhere the problem is reduced. An approach to a solution to this instability problem is to try to (1) introduce a plurality of tunnels in a generally uniformly-distributed manner throughout the network and (2) introduce them all generally at the same time. If successful, under these circumstances, the above-noted instabilities can be reduced and might be avoided. However, this approach is not without frustration because it can be a challenging problem to uniformly introduce a plurality of tunnels into and across a complex network at approximately the same time.
Another problem with tunneling and related to the scenario just described is a traffic congestion problem within the tunnel itself. This problem is created when all or most of traffic upstream of the tunnel's head-end router that is destined for network devices or other nodes downstream of the tunnel's tail-end router would like to use the tunnel to get there. Under these circumstances, traffic-handling capacity of the tunnel can quickly be exceeded and congestion and delay, including loss of information, can result. This problem occurs frequently when using current protocols such as, for example, a currently-popular network protocol known as “Interior Gateway Protocol (IGP) cut through”. IGP cut through is used within local area networks (LANs) or within autonomous systems (ASs) [to be contrasted with wide area networks (WANs) which connect one or more LANs or ASs via gateways]. IGP cut through is described in an IETF (Internet Engineering Task Force) draft entitled “Calculating IGP Routes Over Traffic Engineering Tunnels”, is available on line at “draft-hsmit-mpls-igp-spf-00.txt”, was authored by Messrs. Henk Smit and Naiming Shen and published in June, 1999, and is incorporated by reference herein in its entirety. The main advantage of IGP cut through is that packets with destination addresses downstream of the egress router of a tunnel will automatically use the tunnel without a human operator needing to specify those destinations as part of a forwarding equivalency class (FEC). Thus, all destinations downstream of the tunnel's exit become part of an implied FEC (IFEC). But, using IGP cut through causes the human operator to lose his/her ability to direct traffic through the tunnel which can result in a problem of severe tunnel traffic congestion.
These problems of network instability and tunnel congestion are addressed by the welcome arrival of the present invention which not only offers a solution to these problems but does so while also allowing continued usage of the popular IGP cut through protocol.